Интересную особенность тут обнаружил один из читателей Дукана Эппинга: оказывается в VMware vSphere 5.5 Update 1 при перезапуске/выключении хоста VMware ESXi через консоль DCUI рестарта его виртуальных машин посредством механизма VMware HA не происходит.

Ну то есть, если выключение ESXi делать по клавише <F12> в консоли сервера:

Действительно, в этом случае в логе FDM можно увидеть вот такую запись:

2014-04-04T11:41:54.882Z [688C2B70 info 'Invt' opID=SWI-24c018b] [VmStateChange::SavePowerChange] 
vm /vmfs/volumes/4ece24c4-3f1ca80e-9cd8-984be1047b14/New Virtual Machine/New Virtual Machine.vmx 
curPwrState=unknown curPowerOnCount=0 newPwrState=powered off clnPwrOff=true hostReporting=host-113

Это означает, что VMware vSphere считает, что виртуальные машины были выключены корректно (администратором/хостом), а значит их перезапуск механизмом VMware HA не требуется (параметр clnPwrOff=true).

Совсем другая картина, если мы делаем ребут или выключение VMware ESXi из VMware vSphere Client или vSphere Web Client:

В этом случае в логе FDM мы обнаружим что-то вроде такого:

2014-04-04T12:12:06.515Z [68040B70 info 'Invt' opID=SWI-1aad525b] [VmStateChange::SavePowerChange] 
vm /vmfs/volumes/4ece24c4-3f1ca80e-9cd8-984be1047b14/New Virtual Machine/New Virtual Machine.vmx 
curPwrState=unknown curPowerOnCount=0 newPwrState=powered on clnPwrOff=false hostReporting=host-113

Здесь уже мы видим, что clnPwrOff=false, а значит vSphere полагает, что что-то пошло не так и VMware HA перезапустит виртуальные машины "отказавшего" хоста.

Это поведение актуально для VMware vSphere 5.5 Update 1, но пользователи в комментариях к статье Дункана отмечают, что подобное поведение наблюдается и для vSphere 5.0. Поэтому будет не лишним знать об этом всем тем, кто после настройки отказоустойчивого кластера VMware HA тестирует его работоспособность путем перезагрузки хостов ESXi.

Совсем недавно мы писали про то, что компания StarWind Software выпустила предрелизную версию своего решения для создания отказоустойчивых кластеров хранилищ - StarWind SAN V8 Release Candidate. Там будет огромное количество новых возможностей, которые позволят вывести инфраструктуру виртуальных хранилищ на базе локальных дисков серверов на еще более высокий уровень.

Многих пользователей продукта интересует вопрос, а что будет если оба узла StarWind SAN окажутся недоступны в результате аварии или массового сбоя?

Ответ прост - вам достаточно восстановить и запустить один из узлов, после чего выбрать на нем в Management Console нужное устройство и в его контекстном меню выбрать пункт "Mark As Synchronized":

Это позволит продолжить нормальный рабочий процесс, если неисправность не удается устранить сразу же. Как только оба узла будут подняты в онлайн сразу же произойдет автоматическая синхронизация между ними (ничего отдельно делать не нужно), и все снова будет в порядке.

Если второй узел потерян навсегда - нужно просто развернуть новую ноду и настроить синхронизацию на нее.

Как многие уже слышали, совсем недавно вышла первая версия продукта VMware VSAN, который был выпущен одновременно с релизом обновленной платформы VMware vSphere 5.5 Update 1. Многие уже принялись тестировать это решение, которое (что похвально) теперь работает производительнее своей же бета-версии и в то же время линейно масштабируется по количеству узлов ESXi с точки зрения производительности...

Мы уже очень много писали про технологию VMware VSAN, которая позволяет создать кластер из локальных хранилищ хостов VMware ESXi (например, последнее - тут, тут и тут). На днях стало известно, что 10 марта состоится релиз этого решения, которое будет поставляться как дополнение к VMware vSphere, либо как предустановленное решение на брендовых серверах.

VSAN - один из самых серьезных и сложных продуктов VMware. В его тестировании приняло участие более 12 тысяч пользователей, и вот версия 1.0 уже почти готова.

Какие особенности будут у финальной версии VMware Virtual SAN:

• Технологию Virtua SAN будет поддерживать новый релиз платформы виртуализации vSphere 5.5 Update 1, который, очевидно, будет выпущен вместе с VSAN. Также будет поддерживаться и решение VMware Horizon View.
• Апгрейд бета-версий VSAN на релизную версию поддерживаться не будет.
• Стоимость и комплектация изданий будут известны вместе с выходом продукта 10 марта.
• Обещают, что производительность кластера VSAN будет масштабироваться линейно по мере роста количества узлов в нем.
• В кластере хранилищ VSAN поддерживается до 32-х узлов. Минимально нужно 3 хоста ESXi.
• На одном узле поддерживается работа до 100 виртуальных машин. Всего, таким образом, получается до 3200 машин в кластере.
• Для работы кластера на каждом узле должны быть как SSD-диски (как минимум один), так и HDD-накопители. Если чего-то из этого нет - работать не будет.
• Максимально на одном узле поддерживается до 35 HDD-дисков и до 5 SSD-дисков (один SSD на 7 HDD, то есть каждые 7 дисков обязательно требуют твердотельный диск емкостью около 0.1 от совокупной емкости этих HDD).
• Суммарно поддерживаемая емкость кластера = 35 дисков * 32 хоста = 4.4 петабайта хранилища.
• Где можно использовать VSAN (например): для VDI-инфраструктуры, среднекритичные нагрузки (Tier 2/3) и DR-сценарии (хранилища резервной площадки).
• Минимальная скорость адаптера на хосте ESXi - 1 Гбит, но чтобы все работало надежно, очень рекомендуется строить сеть на адаптерах 10 Гбит. А все потому, что репликация идет синхронно.
• Дедупликации пока не будет.
• Производители оборудования, такие как Dell, HP и Cisco будут поддерживать VSAN и серверы "VSAN Ready". Вот тут можно посмотреть на список совместимого с VSAN оборудования. В день релиза станут доступными аж 13 готовых к VSAN конфигураций.
• Ввод-вывод на узле кластера разгоняли до 2-х миллионов IOPS (IOmeter 100% read, 4KB block size, а также 640K IOPS с профилем нагрузки 70/30 read/write и 4KB block size).
• Многие видели, что поддерживается совместная работа технологии VSAN с некоторыми решениями VMware, такими как vSphere Replication. Теперь также будет поддерживаться vSphere Data Protection for backups, vMotion, DRS, HA и многое другое.

Ну что ж, ждем с нетерпением выхода этой штуки, которая может оказаться весьма полезной многим.

На днях компания Microsoft объявила об обновлении своего средства для планирования инфраструктуры репликации на базе решения Capacity Planner for Hyper-V Replica.

Напомним, что утилиту Capacity Planner for Hyper-V Replica компания Microsoft выпустила еще в мае 2013 года для платформы Windows Server 2012, теперь же продукт поддерживает Windows Server 2012 R2.

Основное назначение планировщика Hyper-V Replica - посчитать необходимую емкость канала репликации и инфраструктуру резервного сайта, основываясь на профиле рабочей нагрузки, имеющейся серверной и сетевой инфраструктуре основной площадки и ее хранилищах. Утилита производит автоматизированный сбор и анализ необходимых метрик, после чего запускается процесс подсчета и предоставляется детальный отчет.

Новые возможности Capacity Planner for Hyper-V Replica:

• Поддержка Windows Server 2012 R2 наряду с обычным Windows Server 2012.
• Поддержка хостов Extended Replica.
• Поддержка виртуальных дисков, размещенных на хранилищах NTFS, CSVFS и общие SMB-ресурсы.
• Мониторинг нескольких отдельных хостов одновременно.
• Улучшенная производительность и масштабируемость - отслеживание до 100 виртуальных машин одновременно.
• Параметры резервной площадки (Replica site) можно не вводить - это для тех, кто еще планирует развертывание DR-инфраструктуры.
• Улучшения в отчетах (например, пиковое использование ресурсов).
• Улучшенная документация.
• Улучшенный рабочий процесс использования утилиты и пользовательского интерфейса.

Кстати, в документации есть раздел о том, как утилиту Capacity Planner for Hyper-V Replica можно использовать для инфраструктуры на базе решения Hyper-V Recovery Manager, о котором мы писали недавно.

Скачать Capacity Planner for Hyper-V Replica и документацию к утилите можно бесплатно по этой ссылке.

На днях компания Microsoft объявила о том, что решение Windows Azure Hyper-V Recovery Manager (HRM) теперь находится в статусе General Availability, что означает не только то, что оно поддерживается в производственной среде, но и попадает под действие SLA-соглашений от Microsoft.

Напомним, что Windows Azure Hyper-V Recovery Manager - это средство управления катастрофоустойчивыми решениями от Microsoft, комбинирующее в себе возможности Windows Azure, System Center Virtual Machine Manager и Hyper-V Replica для восстановления виртуальных машин после сбоев в конфигурации с несколькими датацентрами (на данный момент два - основной и резервный).

Recovery Manager - это облачный сервис, который управляется на стороне платформы Windows Azure, позволяющий задать основную и резервную конфигурации виртуальных машин, включая схему IP-адресации (например, на резервном сайте может быть другая подсеть) и порядок восстановления виртуальных машин.

Таким образом, сторонники VMware, которые раньше в качестве своего преимущества называли наличие катастрофоустойчивого решения VMware SRM, теперь имеют на один аргумент меньше.

В качестве основной технологии репликации между площадками предлагается использовать технику Hyper-V Replica, которая производит асинхронную репликацию на уровне хоста (решение от VMware, впрочем, поддерживает и синхронную на уровне хранилищ).

HRM на стороне Azure не хранит никаких чувствительных данных (только имена сетей, настройки, имена ВМ и прочие метаданные), сам же канал передачи данных надежно шифруется.

С момента выпуска октябрьской версии сервиса Microsoft HRM обзавелся следующими возможностями:

• Improved Failback Support - улучшенный механизм для сценария обратного восстановления, когда основная площадка "пришла в себя" после сбоя.
• Support for Kerberos based Authentication - использование этого типа аутентификации для техники Hyper-V Replica. Это полезно, когда у вас в компании используются сторонние WAN-оптимизаторы.
• Support for Upgrade from VMM 2012 SP1 to VMM 2012 R2 - теперь поддерживается обновление Virtual Machine Manager с версии 2012 SP1 на версию VMM 2012 R2.
• Improved Scale - сервис был значительно улучшен в плане масштабируемости.

Ценообразование на HRM строится на базе оплаты за защищаемую виртуальную машину в месяц. При этом берется среднее количество защищаемых виртуальных машин за прошедший месяц. Цена на HRM начинается от ?11.92 / $ 16 за виртуальную машину. При этом до 28 февраля включительно продукт можно приобрести со скидкой 50% по цене от ?5.96 / $ 8 за защищаемую ВМ.

Более подробно о решении Windows Azure Hyper-V Recovery Manager можно узнать на этой странице.

Мы уже много писали о технологии VMware Virtual SAN (VSAN), которая позволяет создать отказоустойчивый кластер хранилищ для виртуальных машин на основе комбинации SSD+HDD локальных дисков серверов VMware ESXi. Не так давно вышла обновленная бетаэтого решения, кроме того мы не так давно писали о производительности VSAN тут.

В этой заметке (на базе статьи Дункана) мы поговорим о том, как кластер VSAN обрабатывает сбои различного типа, и как происходит восстановление работоспособности виртуальной машины без ее простоя.

Итак, в нормальном режиме функционирования, при значении параметра FailuresToTolerate равном 1, который означает, какое количество отказов хостов может пережить кластер хранилищ, реплика одного VMDK будет размещена на дисках еще одного из хостов кластера:

Тут можно заметить 5 особенностей кластера VMware VSAN:

• Виртуальный диск VMDK и его реплика всегда находятся на разных хост-серверах VMware vSphere.
• ВМ не обязательно должна исполняться на том хосте ESXi, на дисках которого находятся ее хранилища.
• Компонент witness находится на третьем по отоношению к виртуальному диску и его реплике хосте, чтобы создать определенность на случай разделения сети VSAN (где окажется 2 компонента из набора "vmdk-реплика-witness" - тот сегмент и будет определяющим).
• Сеть VSAN используется для операций ввода-вывода и определения доступности.
• Реплика VMDK-диска вместе с основной копией образуют RAID-1 массив, который увеличивает производительность операций чтения в виртуальной машине, так как для чтения используются оба хранилища.

Кроме того, вследствие особенностей реализации кластера VSAN, надо понимать, что команды ввода-вывода не применяются к диску данных виртуальной машины, пока не пришло подтверждение об их записи на реплике. Но подтверждение приходит не от HDD-диска, где находятся данные ВМ (это было бы очень медленно), а от SSD-диска, который используется как энергонезависимый Write Buffer для команд ввода вывода. Таким образом, этот буфер (и данные, само собой) зеркалирован в рамках дисковой группы на другом хосте ESXi.

Теперь рассмотрим различные виды сбоев в кластере VSAN.

1. Ломается диск дисковой группы, где исполняется виртуальная машина.

Выглядит это так:

В этом случае такой диск сразу же помечается как "degraded", а команды ввода-вывода перенаправляются на другой хост-сервер VMware ESXi. При этом виртуальная машина этого не замечает, так как переключается на работу с SSD-буфером/кэшем и HDD-дисками другого хоста мгновенно (данные на момент сбоя были синхронизированы, ничего не потерялось).

Одновременно с этим сразу же начинается процесс построения реплики на другом хосте ESXi в рамках его дисковой группы, при этом проверяется, достаточно ли там свободных дисковых ресурсов. Если их недостаточно, то механизм VSAN будет ожидать. Как только вы добавите диски/дисковые группы на хостах - сразу же начнется процесс построения реплики (до его окончания машина будет помечена как "degraded").

Тут надо отметить, что в degraded-состоянии скорость записи данных останется прежней, простоя не будет, а вот скорость чтения упадет до построения новой реплики, поскольку второй копии данных пока нет.

2. Отказывает хост VMware ESXi целиком.

В этом случае запускать процесс восстановления сразу же, конечно, не нужно - мало ли что могло случиться с хостом, например, его случайно перезагрузили, или временно пропало сетевое соединение.

В этом случае происходит ожидание в течение 60 минут, и если отказавший хост ESXi не оживет, то начнется процесс создания реплики виртуального диска VMDK на другом хосте. Это время можно изменить в расширенной настройке кластера VSAN.ClomRepairDelay, но пока не известно будет ли это поддерживаться со стороны VMware.

3. Отказ SSD-диска в дисковой группе.

В кластере VMware Virtual SAN поддерживается 1 SSD-диск и до 7 HDD-дисков в одной дисковой группе. Всего на один хост VMware ESXi поддерживается до 5 дисковых групп.

В данном случае Failure Domain - это вся дисковая группа, включающая в себя SSD-диск, который используется для двух типов операций:

• Read Cache (70% емкости) - безопасное кэширование операций на чтение. На SSD-диске хранятся наиболее часто используемые блоки, что уменьшает I/O read latency для ВМ.
• Write Buffering (30% емкости) - когда приложение внутри гостевой ОС пытается записать данные, оно получает подтверждение записи тогда, когда данные фактически записаны на SSD (не на HDD), таким образом твердотельный накопитель используется как буфер на запись, что небезопасно при внезапном пропадании питания или отказе хоста. Поэтому данные этого буфера дублируются на других хостах кластера и их SSD-дисках.

Таким образом, при отказе SSD-диска, виртуальная машина начинает использовать реплику на уровне всей дисковой группы на другом хосте VMware ESXi. Вот почему выгодно делать две дисковых группы 3HDD+1SSD, чем одну  6HDD+1SSD.

Вот, в общем-то, и все. Более подробно об использовании SSD-дисков, их производительности и ресурсе можно прочитать вот в этой статье.

Коллеги рассказали про интересный случай: создали RDM-диск для двух виртуальных машин MSCS-кластера "across boxes", подцепили его к виртуальным машинам на двух хостах ESXi, а производительность на нем упала до 10 МБ/сек, хотя этот диск находится на быстром FC-хранилище EMC VNX и скорость должна измеряться сотнями МБ/сек. При этом в качестве хост-платформы используется VMware vSphere 5.1.

Ответ оказался простым - для хранилищ EMC VNX хост ESXi выставляет политику путей по умолчанию Round Robin (балансировка по двум путям). При использовании кластера MSCS на кворумном диске вызываются SCSI-3 резервации. SCSI-3 резервация (registration) посланная по одному пути позволяет производить дальнейшие резервации или SCSI-команды только по этому пути.

А при использовании политики Round Robin, когда плагин PSP_RR переключает на другой путь, кластер MSCS получает ошибку и пробует сделать SCSI-3 резервацию повторно или выполнить другие команды.

Поэтому вместо политики Round Robin для конкретного хранилища и для данного RDM-диска надо использовать следующие политики путей (плагины PSP_MRU или PSP_FIXED), в зависимости от типа хранища. Они приведены в KB 1010041 и в таблице ниже:

Для того, чтобы выставить политику путей, нужно в разеле Storage в vSphere Client выбрать нужный HBA-адаптер и устройство, для которого создан RDM-диск, и из его контекстного меню выбрать пункт Manage Paths (это также можно сделать в свойствах виртуальной машины для диска):

После выставления корректной политики путей скорость для кворумного диска MSCS вырастет в разы. Кстати, если вы используете VMware vSphere 5.5 и выше, то такого поведения там уже нет, и все работает корректно.

О новых возможностях VMware vSphere 5.5 по поддержке кластеров MSCS мы уже писали вот тут.

При каждом релизе платформы виртуализации VMware vSphere неизменно возникают вопросы о том, что же изменилось в плане поддержки гипервизором ESXi кластеров Microsoft Clustering Services (MSCS). Напомним, что базовая информация об этом находится здесь.

Вот какие варианты развертывания кластеров MSCS для различных приложений поддерживает VMware vSphere 5.5 (напомним, что о кластерах MSCS мы писали тут, тут и тут):

А вот какие версии и конфигурации кластеров Microsoft поддерживаются для различных верси гостевых ОС Windows Server и VMware vSphere:

А теперь перейдем к нововведениям, касающимся поддержки MSCS в VMware vSphere 5.5:

1. Во-первых, к общему хранилищу узлов кластера MSCS может быть организован доступ по нескольким путям посредством политики Round Robin (модуль PSP_RR). Ранее это сделать было нельзя ввиду проблем со SCSI reservations. Теперь эта проблема решена.

Однако тут есть ограничения:

• Поддерживается только для гостевых ОС Windows 2008 и Windows 2012.
• Поддерживаются только конфигурации Cluster Across Boxes (CAB) и N+1. Системы "Cluster in a box" (CIB) используют Virtual Reservations.
• Общий диск (Quorum или Data) должен быть развернут в режиме pass-through RDM.

2. Во-вторых, появилась поддержка протоколов FCoE & iSCSI. Ранее полноценно в качестве общего хранилища для кластеров MSCS поддерживались только  хранилища Fibre Channel, с оговорками iSCSI и как-то частично FCoE. Теперь же полноценно можно использовать iSCSI и FCoE хранилища.

А именно:

• Все конфигурации кластеров: CAB, CIB и N+1 поддерживаются iSCSI.
• Поддержка адаптеров iSCSI:
  
  • Software iSCSI;
  • Аппаратные адаптеры QLogic, Emulex и Broadcom.
• Поддержка режима Mixed mode для iSCSI-инициатора.
• До 5 узлов в кластере поддерживается для Windows 2008 SP2 и более поздних версий.

3. В-третьих, появилась поддержка кластеризации гостевых ОС Windows 2012 MSCS.

Если все это обобщить, то получится картинка, взятая отсюда:

Больше подробностей о поддержке MSCS в VMware vSphere 5.5 можно узнать из KB 2052238.

За множеством анонсов VMworld Europe 2013 пользователи платформы виртуализации VMware vSphere могли упустить несколько полезных релизов.

Во-первых, вышла новая версия VMware vSphere 5.0 Update 3:

Это сервисный релиз, включающий в себя следующие возможности:

• Поддержка новых гостевых ОС (более детальная информация в Guest OS Customization Support Matrix).
• Добавлена поддержка БД  Microsoft SQL Server 2012 Service Pack 1.
• Множество исправлений (подробнее в Resolved Issues).

Информация о гипервизоре ESXi 5.0 Update 3 и остальных компонентах приведена по этим ссылкам: esx-base, misc-drivers, scsi-hpsa, tools-light

Во-вторых, обновилась и VMware vSphere 5.1:

• Вышел vCenter 5.1 Update 1c
• Обновились компоненты VMware ESXi 5.1: esx-base and misc-drivers, net-ixgbe, tools-light, 

В этом билде были только исправлены баги и не добавилось новых возможностей. Кстати, для интересующихся есть интересная матрица билдов, позволяющая сверить версии компонентов своей виртуальной инфраструктуры.

Кроме всего прочего обновился и HP Customized ESXi 5.0.

В-третьих, вышел HP Customized ESXi 5.5 ISO

Это хорошая новость для тех, кто использует серверы HP и все ждет, как бы начать развертывать на них образы ESXi. Сам образ HP Customized ESXi 5.5 ISO доступен тут. Традиционно, драйверы устройств и различные бандлы доступны в VIB-репозитории HP.

Кстати, ранее этот образ уже выкладывала HP, но там была бага с CIM-провайдерами, которая поправлена в этом билде. Что нового в HP Customized ESXi 5.5 :

• Убрана поддержка старых серверов, а именно: всех моделей G5 и множества G6 (более подробно в ProLiant Server VMware Support Matrix).
  Но это не значит, что там ESXi 5.5 не будет работать.
• Утилита hpacucli для конфигурации контроллеров хранилищ из командной строки ESXi была заменена на утилиту hpssacli, которая поддерживает больше контроллеров.
• Новая утилита hptestevent, которая теперь может посылать тестовые события WBEM, что может пригодиться для проверки корректности работы механизма WBEM/CIM (проверка, что хост правильно зарегистрирован в HP SIM для мониторинга аппаратного обеспечения).

Процедура обновления HP-сервера с образа vSphere 5.0 или 5.1 на HP customized ESXi 5.5:

• Загружаем HP Customized ESXi 5.5 Offline bundle (zip-файл) отсюда.
• Загружаем его на датастор хоста ESXi и выполняем команду:

esxcli software profile install -d /vmfs/volumes/<datastore>/VMware-ESXi-5.5.0-1331820-HP-5.71.3-Sep2013-depot.zip -p HP-ESXi-5.5.0-5.71.3

• Перезагружаем хост VMware ESXi.

Мы уже не раз писали (тут и тут) про расширенные настройки (Advanced Settings) кластеров VMware HA в VMware vSphere (до версии 5.0 включительно). Эти настройки позволяют гибко настраивать различные параметры кластеров, их поведение, определять сетевые настройки и т.п. В этой статье мы приведем все эти настройки в единую таблицу и актуализуем для версии VMware vSphere 5.5.

Мы уже давно пишем о решениях StarWind, которые позволяют создавать отказоустойчивые хранилища для виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V. Хранилища, построенные на базе технологии StarWind iSCSI, не требуют дополнительных инвестиций в инфраструктуру сети хранения, работают на базе проверенного протокола iSCSI и имеют функции отказоустойчивости на базе двух или трехузловых кластеров.

Между тем, далеко не все знают, что решения StarWind можно использовать и для других платформ виртуализации, в частности, Citrix XenServer. Тем более, что если под платформы VMware и Microsoft есть конкурирующие решения, то для платформы XenServer программных хранилищ с функциями высокой доступности - очень мало. Поэтому пользователям XenServer весьма полезно будет почитать документ "StarWind iSCSI SAN & NAS: Providing HA Shared Storage for XenServer", где рассказывается о развертывании двухузлового кластера хранилищ для виртуальных машин.

Документ свежий - от июня этого года.

Мы часто рассказываем о продуктах StarWind iSCSI SAN and NAS и StarWind Native SAN for Hyper-V, предназначенных для создания отказоустойчивых хранилищ виртуальных машин для платформ VMware и Hyper-V в частных облаках предприятий. Хранилища, построенные на базе технологии StarWind iSCSI, не требуют дополнительных инвестиций в инфраструктуру сети хранения, работают на базе проверенного протокола iSCSI и имеют функции отказоустойчивости на базе двух или трехузловых кластеров.

Сегодня мы хотим осветить один важный вопрос, касающийся лицензирования продуктов StarWind. Если вы зайдете на страницу изданий одного из продуктов StarWind, то увидите, что есть издание StarWind iSCSI SAN & NAS 1-node CDP Edition, для которого не ограничена емкость создаваемых виртуальных дисков и устройств:

Следующие - это HA-издания, которые позволяют создать распределенное отказоустойчивое хранилище для 2-х или 3-х узлов серверов хранения:

Здесь уже указано ограничение на объем дискового пространства под виртуальные машины, в зависимости от приобретаемой лицензии на StarWind iSCSI SAN & NAS или StarWind Native SAN.

Так вот - эти ограничения касаются только HA-устройств, а все остальные типы виртуальных дисков StarWind можно создавать в неограниченных количествах и объемах, точно так же, как и в CDP-издании. Пруфлинк - тут.

Мы часто рассказываем о продуктах StarWind iSCSI SAN and NAS и StarWind Native SAN for Hyper-V, предназначенных для создания отказоустойчивых хранилищ виртуальных машин для платформ VMware и Hyper-V в частных облаках предприятий. Хранилища, построенные на базе технологии StarWind iSCSI, не требуют дополнительных инвестиций в инфраструктуру сети хранения, работают на базе проверенного протокола iSCSI и имеют функции отказоустойчивости на базе двух или трехузловых кластеров.

На блоге sensiblecyber.com появилось хорошее видео, описывающее процесс развертывания и настройки двухузлового отказоустойчивого кластера StarWind Native SAN for Hyper-V. Сначала дается немного теории, а затем на практике показывается весь несложный процесс:

У этого же автора есть хорошая статья, описывающая развертывание и настройку кластера StarWind Native SAN for Hyper-V.

Компания StarWind Software, производитель средства номер 1 для создания отказоустойчивых хранилищ iSCSI для виртуальных машин VMware и Microsoft, выпустила интересный документ "HA Maintenance and Configuration Changes". В нем можно почитать о том, как необходимо производить обслуживание узлов StarWind iSCSI SAN, а также как правильно выполнять настройку узлов в отказоустойчивой конфигурации.

Документ будет полезен не только администраторам хранилищ StarWind, но и всем тем, кому интересно, как функционирует отказоустойчивое хранилище, как синхронизируются узлы, и как необходимо их обслуживать.

Операции, описанные в документе:

• замена узла-партнера, на который идет синхронная репликация данных
• ручная синхронизация узлов
• подготовка HA-устройства к обслуживанию и простою
• восстановление работоспособности узла после запланированного простоя
• изменение каналов синхронизации и сигналов доступности (heartbeats)
• настройка CHAP-аутентификации для HA-устройства

Документ "HA Maintenance and Configuration Changes" компании StarWind можно скачать по этой ссылке.

Компания StarWind Software, производитель средства номер 1 для создания отказоустойчивых хранилищ iSCSI для виртуальных машин VMware и Microsoft, выпустила интересный документ "StarWind High Availability Best Practices", где описаны лучшие практики для механизмов отказоустойчивости, имеющихся в продукте:

Данный документ подойдет как новичкам, так и опытным администраторам СХД StarWInd, поскольку в нем имеется описание необходимых настроек ОС, сетевого взаимодействия, тиминга адаптеров, канала синхронизации, а также имеются рекомендации по настройке HA-устройств, снабженные иллюстрациями.

Продолжаем рассказывать о решении для создания отказоустойчивой инфраструктуры хранения виртуальных машин для платформы Hyper-V - StarWind Native SAN. Недавно, кстати, мы писали о том, что появилось бесплатное издание StarWind Native SAN for Hyper-V Free edition с функциями отказоустойчивости хранилищ хост-серверов.

На этот раз предлагаем вашему вниманию документ "Virtualization Reality: Why StarWind Virtual SAN Solutions Deliver Value When Compared to Microsoft", в котором рассмотрены 5 причин, исходя из которых решение StarWind Native SAN имеет преимущества и ценность по сравнению со встроенными средствами Microsoft Hyper-V, такими как Shared Nothing Live Migration, Hyper-V Replica и механизмом кластеризации через SMB 3.0.

Также в документе, помимо всего прочего, рассмотрены архитектуры Scale-Out File Servers, о которой мы уже писали вот тут, и построение кластеров Microsoft на базе дисковых полок SAS JBOD. Как не трудно догадаться, все это хуже, чем решение StarWind Native SAN.

Компания StarWind Software, производящая продукт номер 1 для создания отказоустойчивых хранилищ StarWind iSCSI SAN & NAS, приглашает на бесплатный вебинар "Increase Operational Efficiency with StarWind!", который проводит Анатолий Вильчинский, системный инженер StarWind Software.

На вебинаре будет рассказано о том, как с помощью решений StarWind можно улучшить эффективность хранения данных виртуальных серверов за счет функций дедупликации, а также функций высокой доступности хранилищ (напомним, что использовать их можно бесплатно).

Вебинар состоится в четверг, 24 января в 19-00 по московскому времени. Регистрируйтесь!

Многим интересующимся технологиями виртуализации известна компания Stratus Technologies, занимающаяся вопросами непрерывной доступности виртуальных машин (Fault Tolerance). Ранее продукты этой компании были доступны на платформе Citrix XenServer, где позволяли обеспечивать непрерывную доступность программными методами (продукт everRun от купленной компании Marathon):

Теперь у компании появился программно-аппаратный комплекс Stratus ftServer systems with vSphere 5.1, интегрированный с последней версией платформы виртуализации от VMware. Возможности решения из пресс-релиза:

• Обещают аптайм на уровне 99.999%, что соответствует 5.26 минут простоя в год
• Один или два 8-ядерных процессора Intel с поддержкой hyper-threading и архитектуры QuickPath
• Полная поддержка SMP для построения архитектуры непрерывной доступности (vSMP?)
• Встроенные интерфейсы 10Gb Ethernet
• Проактивная система мониторинга, предупреждающая о возможных сбоях
• Система обнаружения проблем в самом сервере и операционной системе, работающая без прерывания обслуживания виртуальных машин
• Минимальный overhead (<5%) на систему виртуализации
• Интеграция с VMware HA

Очевидно, что Stratus суетится накануне выхода программного vSMP Fault Tolerance от самой VMware.

Кстати в пресс-релизе по ftServer говорится о полугодовой гарантии на нулевой даунтайм в $50 000, покрывающей не только серверную часть, но и гипервизор (!). Так что торопитесь - возможно, парочка серверов от Stratus достанется вам совершенно бесплатно (учитывая тот набор багов, который мы видим в vSphere 5.1).

Мы уже много писали про продукт номер 1 для создания отказоустойчивых хранилищ StarWind iSCSI SAN 6.0, в том числе про экономическую эффективность решения и его новые возможности. Многие знают, что у StarWind есть хорошая подборка материалов по настройке и эксплуатации данного продукта.

Сегодня мы хотим обратить ваше внимание на документ "StarWind iSCSI SAN & NAS: Multipathing", в котором детально и по шагам рассказывается о настройке механизма доступа по нескольким путям (MPIO) при использовании сервера хранилищ StarWind iSCSI SAN. В руководстве рассматривается настройка серверов на базе следующей схемы подключения:

В документе описаны способы настройки серверов как на платформе Windows Server 2008, так и Windows Server 2012.

Известный многим Duncan Epping в своем блоге рассказал об изменениях, которые произошли в механизме обнаружения события изоляции хост-сервера ESXi в VMware vSphere 5.1. Приведем их вкратце.

Как мы уже писали вот тут, кластер VMware HA следующим образом обрабатывает событие изоляции (отсутствие коммуникации с другими серверами кластера):

T+0 сек – обнаружение изоляции хоста (slave)
T+10 сек – хост slave переходит в режим выбора (“election state”)
T+25 сек – хост slave объявляет себя мастером (master)
T+25 сек – хост slave пингует адреса isolation addresses (по умолчанию один)
T+30 сек – хост slave объявляет себя изолированным и инициирует действие, указанное в isolation response

В VMware vSphere 5.1 появилось небольшое изменение, выражающееся в том, что хост ждет еще 30 секунд после объявления себя изолированным до инициации действия isolation response. Это время можно отрегулировать в следующей расширенной настройке кластера:

das.config.fdm.isolationPolicyDelaySec.

Таким образом, теперь последовательность выглядит так:

T+0 сек – обнаружение изоляции хоста (slave)
T+10 сек – хост slave переходит в режим выбора (“election state”)
T+25 сек – хост slave объявляет себя мастером (master)
T+25 сек – хост slave пингует адреса isolation addresses (по умолчанию один)
T+30 сек – хост slave объявляет себя изолированным и
T+60 сек - хост инициирует действие, указанное в isolation response

Наглядно:

Данные изменения были сделаны, чтобы обрабатывать сценарии, где не действие isolation response при наступлении изоляции хоста нужно обрабатывать через длительное время или не обрабатывать совсем.

Мы уже писали о том, что средствами StarWind iSCSI SAN 6.0 можно создать трехузловой отказоустойчивый кластер хранилищ для виртуальных машин VMware vSphere (+ про экономический эффект). А на днях вышел документ "StarWind iSCSI SAN & NAS: Configuring 3-node HA Shared Storage for vSphere", описывающий настройку целевой архитектуры такого кластера:

В документе подробно описаны процессы создания HA-устройств, настройка каналов синхронизации, а также необходимые конфигурации серверов VMware ESXi.

Не так давно мы писали о том, что компания StarWind Software объявила сразу о трех релизах, одним из которых был выпуск новой версии решения для создания отказоустойчивых хранилищ под платформу Hyper-V - StarWind Native SAN for Hyper-V 6.0.

В этой статье мы расскажем о новых возможностях, которое приобрело это средство номер 1 для создания iSCSI-хранилищ под виртуализацию Hyper-V.

Итак, что нового:

• Много улучшений High Availability. Во-первых, улучшился уровень юзабилити - теперь интерфейсы выглядят проще и работают быстрее. Многие операции снабжены мастерами. Во-вторых, улучшился движок HA - теперь можно производить операции add, remove и switch для HA-узла без вывода его в режим "Offline".
• Новые функции HA-устройств. Теперь в качестве HA-устройств могут быть использованы такие девайсы как deduplicated, thin-provisioned IBV или DiskBridge. Это означает, что теперь доступна функциональность дедупликации, thin provisioning, снапшоты и прочее для HA-устройств.
• Улучшения дедупликации:
• Asynchronous replication of deduplicated data - теперь данные для репликации по медленным каналам (WAN) могут передаваться асинхронно, что позволяет использовать решение в DR-сценариях. Кроме того, теперь любой тип устройства может быть целевым для репликации.
• Deletion of unused data - неиспользуемые блоки, появляющиеся на дедуплицируемом хранилище, записываются актуальными данными, что позволяет использовать пространство более эффективно.
• Decreased memory usage - в этой версии StarWind Native SAN на 30% снижены требования к памяти сервера. Теперь при использовании блоков 4 KB только 2 МБ оперативной памяти требуется на 1 ГБ хранимых данных.
• Полная поддержка Windows Server 2012.

Скачать StarWind Native SAN for Hyper-V 6.0 можно по этой ссылке. И напоминаем, что у этого решения есть полнофункциональная бесплатная версия.

Продолжаем вас знакомить с решением номер 1 для сертифицированной защиты виртуальной инфраструктуры VMware vSphere средствами политик - vGate R2 от компании Код Безопасности. Сегодня мы поговорим о том, как работает механизм резервирования основного компонента защиты инфраструктуры vGate R2 - сервера авторизации. В стандартном режиме работы основной сервер авторизации проксирует через себя все соединения клиентов vSphere к серверам виртуальной инфраструктуры, а реплики конфигурации передает на резервный сервер...

Мы уже писали о новых возможностях продукта номер 1 для создания откзоустойчивых хранилищ виртуальных машин StarWind iSCSI SAN & NAS 6.0, а также анонсировали вебинар "Что нового в версии 6.0", который прошел 24 октября. Для тех, кто пропустил это мероприятие, компания StarWind выложила запись этого вебинара на русском языке, который традиционно ведет наш коллега Анатолий Вильчинский.

Вы также можете скачать видеозапись вебинара в формате FLV.

Как вы знаете, недавно вышла финальная версия продукта StarWind iSCSI SAN & NAS 6.0, которая позволяет строить трехузловые кластеры непрерывной доступности хранилищ, которые экономически и технически более целесообразны, чем двух узловые.

Завтра, в 16-00 по московскому времени, Анатолий Вильчинский, системный инженер StarWind Software, проведет для вас интересный вебинар "Что нового в версии 6.0".

Не часто выпадает возможность послушать на русском языке о новой версии продукта от вендора. Поэтому регистрируйтесь и приходите.

О новых возможностях продукта StarWind iSCSI SAN & NAS 6.0 можно прочитать у нас тут.

Компания StarWind, производитель решения номер 1 - StarWind iSCSI SAN, которое предназначено для создания отказоустойчивых iSCSI-хранилищ для платформ виртуализации VMware vSphere и Microsoft Hyper-V, объявила о начале новой промо-акции. Как вы знаете, недавно вышла финальная версия продукта StarWind iSCSI SAN 6.0, которая позволяет строить трехузловые кластеры непрерывной доступности хранилищ, которые экономически и технически более целесообразны, чем двух узловые.

Так вот, только до конца года, купив один из продуктов StarWind iSCSI SAN & NAS или StarWind Native SAN for Hyper-V, вы бесплатно получаете возможность развернуть 3-узловую конфигурацию по цене 2-узловой:

Подробности предложения указаны здесь. Приобрести продукты StarWind можно по этой ссылке. Бесплатная версия StarWind - тут.

Одновременно с анонсом новой версии платформы VMware vSphere 5.1 компания VMware объявила об обновлении средства VMware vSphere Storage Appliance 5.1 (VSA), которое позвляет организовать общее отказоустойчивое хранилище для виртуальных машин на базе локальных дисков хост-серверов VMware ESXi с использованием двух или трех узлов. О новых возможностях VSA предыдущей версии (1.0) мы уже писали вот тут, а сегодня расскажем о новых возможностях и лицензировании версии 5.1.

Итак, что нового появилось в VMware vSphere Storage Appliance 5.1:

Максимально поддерживаемые характеристики локальных хранилищ серверов ESXi теперь таковы:

3 ТБ диски

• 8 дисков до 3 ТБ каждый в конфигурации RAID 6 (без hot spare)
• 18 ТБ полезной емкости под тома VMFS-5 на 1 хост
• 27 ТБ полезной емкости на 3 хоста

2 ТБ диски

• 12 локальных дисков до 2 ТБ в конфигурации RAID 6 (без hot spare)
• 16 внешних дисков до 2 ТБ в RAID 6 (вместе с hot spare)
• VMware поддерживает максимальный размер тома VMFS-5 size до 24 ТБ на хост в VSA 5.1
• 36 ТБ полезной емкости на 3 хоста

Ранее, в VSA 1.0, установка vCenter не поддерживалась на хранилищах узлов, входящих в VSA-кластер. Теперь можно устанавливать vCenter на одно из локальных хранилищ серверов, не входящее в общее пространство VSA. В этом случае, при создании общей емкости VSA можно выставить размер общего пространства, оставив нужное место на локальном VMFS под vCenter:

Эта же возможность относится и к установке VSA на существующих хостах ESXi, где на локальных дисках уже есть виртуальные машины. Администратор сначала создает общее пространство VSA на хостах кластера, а потом с помощью Cold Migration переносит в общий том VMFS эти виртуальные машины. Освободившееся место можно присоединить к пространству VSA за счет функции увеличения емкости.

Емкость хранилищ VSA может быть увеличена на лету за счет добавления новых дисков. Можно добавить новый Extent к тому VMFS, а можно пересоздать RAID и сихнронизировать его с другим узлом кластера:

Также теперь с одного сервера vCenter можно управлять сразу несколькими кластерами VMware VSA, каждый из которых состоит из двух или трех узлов. Таких кластеров может быть до 150 штук для одного vCenter. Это хорошо подходит для организаций, имеющих распределенную инфраструктуру филиалов, где, как известно, денег на покупку общих систем хранения обычно нет (ROBO-сценарии).

Модуль VMware VSA 5.1 можно использовать для различных сценариев и всех изданий VMware vSphere 5, кроме самого низшего - Essentials:

Возможности продукта для всех изданий полностью идентичны, кроме того, что VSA for Essentials Plus не может управлять несколькими кластерами VSA, поскольку очевидно, что нужна лицензия vCenter Standard. Если же VSA 5.1 используется для Essentials Plus в конфигурации ROBO (то есть, несколько сайтов, объединенных единой точкой управления) - то так делать можно.

Кстати о лицензии на vCenter Standard - раньше для пользователей Essentials Plus она временно требовалась, когда вы заменяли один из узлов кластера. Теперь такой необходимости нет.

На эту тему можно также почитать документ "What's New in VMware vSphere Storage Appliance 5.1".

Мы уже писали о недавно вышедшей обновленной бета-версии решения для создания отказоустойчивых хранилищ StarWind iSCSI SAN 6.0, где появилось множество новых возможностей, в том числе трехузловая архитектура кластеров хранилищ.

Компания StarWind выпустила краткий и понятный документ "Why 3-Way Synchronous Mirroring Is Better Than 2-Way?", где объясняются преимущества треузлового кластера StarWind iSCSI SAN перед двухузловым.

Причины, по которым желательно использоват трехузловой кластер, таковы:

1. Цена.

Если для двухузлового кластера рекомендуется дополнительный уровень отказоустойчивости на уровне RAID (например, RAID10), то вы получаете только 25% полезной емкости дисковых устройств (50% тратится на RAID и 50% остатка на поддержание синхронной копии). Для трехузлового же кластера можно обойтись RAID0, так как данные находятся на дисковых устройствах сразу трех узлов (можно использовать RAID0 или JBOD). Поэтому вы получаете 33% полезной емкости:

2. Надежность.

Очевидно, что три узла надежнее, чем два. Дополнительный уровень надежности, позволит обеспечить запросы самых критичных приложений предприятия.

К тому же, в первом случае, при выходе из строя одного из узлов, вы теряете 50% MPIO-путей, а во втором - только 33%.

3. Высокая производительность.

Когда в трехузловом кластере вы используете RAID0 - то данные с дисков читаются максимально быстро, а скорость записи ничем не уступает конфигурации с двухузловым кластером и RAID10. Кроме того, при выходе из строя узла в двухузловом кластере, кэш на втором узле очищается и переводится врежим write-through, что уменьшает производительность, а также вся система переходит в режим "degraded mode".

В случае с трехузловым кластером политики кэширования write-back сохраняются и потери производительности минимальны (приходим к обычному двухузловому кластеру).

Больше о продукте StarWind iSCSI SAN можно узнать здесь.

Компания StarWind Software объявила о выпуске публичной бета-версии решения номер 1 для создания отказоустойчивых хранилищ для серверов VMware vSphere и Microsoft Hyper-V - StarWind iSCSI SAN 6.0.

О версии StarWind 5.9 мы уже писали, так вот она, не перетекая в релиз, превратилась в бету StarWind iSCSI SAN 6.0, чтобы выйти уже со всеми новыми возможностями в мажорном обновлении.

Новые возможности StarWind iSCSI SAN 6.0:

• Улучшенное управление HA-устройствами. Теперь можно добавить новый узел кластера StarWind к HA-устройству, удалить узел или переключиться между ними без необходимости заново пересоздавать HA Device.
• HA-устройство может использовать другие типы устройств StarWind для хранения данных. Это может быть дедуплицированный диск, "тонкое" устройство IBV или устройство типа DiskBridge.
• Асинхронная репликация для дедуплицированных хранилищ. Любой iSCSI target может быть использован как хранилище назначения для репликации.
• Возможность загрузки бездисковых серверов по iSCSI для хранилищ StarWind. Подробно процедура настройки этой функции описана в документе "StarWind iSCSI Boot".
• Улучшенное резервное копирование для виртуальных машин VMware ESX/ESXi.
• Некоторые дополнительные возможности для резервного копирования виртуальных машин на Hyper-V.
• Новый GUI для управления процессом резервного копирования (интегрирован в Management Console).
• Упрощенный процесс подключения серверов Hyper-V и ESXi.

Скачать бета-версию StarWind iSCSI SAN 6.0 можно по этой ссылке. Более подробно о новых возможностях можно прочитать на форуме.